Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Scala generation support. #32

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nbauernfeind
Copy link

@nbauernfeind nbauernfeind commented May 24, 2018

It would greatly simplify stellar's scala sdk (see Synesso/scala-stellar-sdk#13) to use an interface that more natively integrated with Scala than the Java API.

This change adds full generation support for scala. It was tested by generating source code for stellar-core's XDR classes and compiling them with scalac. More thorough testing is TBD.

This is a portion of my contribution for the Stellar Build Challenge 7.

@Synesso
Copy link
Contributor

Synesso commented May 27, 2018

Thanks Nate. This is looking good.

After running rspec I attempted to compile the results. There were 2 compilation errors & also the warning about classes overwriting on case-insensitive filesystems (I think we agreed this was not a dealbreaker, but I was under the impression that modern Windows systems are case-sensitive - however this doesn't seem to be the case. We probably should avoid case-insensitive class filename collisions).

$ for d in `ls`; do (echo $d; cd $d && scalac *.scala); done
block_comments.x
const.x
TestArray.scala:20: error: not found: value FOO
  def decode(stream: XdrDataInputStream): TestArray = TestArray((0 until FOO).map(_ => stream.readInt).toArray)
                                                                         ^
one error found
enum.x
nesting.x
MyUnion.scala:59: warning: Class MyXDR.MyUnion$One differs only in case from MyXDR.MyUnion$ONE. Such classes will overwrite one another on case-insensitive filesystems.
  case class One (
             ^
MyUnion.scala:67: warning: Class MyXDR.MyUnion$One$ differs only in case from MyXDR.MyUnion$ONE$. Such classes will overwrite one another on case-insensitive filesystems.
  object One {
         ^
MyUnion.scala:72: warning: Class MyXDR.MyUnion$Two differs only in case from MyXDR.MyUnion$TWO. Such classes will overwrite one another on case-insensitive filesystems.
  case class Two (
             ^
MyUnion.scala:82: warning: Class MyXDR.MyUnion$Two$ differs only in case from MyXDR.MyUnion$TWO$. Such classes will overwrite one another on case-insensitive filesystems.
  object Two {
         ^
four warnings found
optional.x
struct.x
test.x
OptHash1.scala:16: error: value encode is not a member of Option[MyXDR.Hash]
    self.encode(stream)
         ^
OptHash1.scala:20: error: type mismatch;
 found   : MyXDR.Hash
 required: Option[MyXDR.Hash]
  def decode(stream: XdrDataInputStream): OptHash1 = OptHash1(Hash.decode(stream))
                                                                         ^
OptHash2.scala:16: error: value encode is not a member of Option[MyXDR.Hash]
    self.encode(stream)
         ^
OptHash2.scala:20: error: type mismatch;
 found   : MyXDR.Hash
 required: Option[MyXDR.Hash]
  def decode(stream: XdrDataInputStream): OptHash2 = OptHash2(Hash.decode(stream))
                                                                         ^
four errors found
union.x

@nbauernfeind
Copy link
Author

@bartekn The ideal testing I have in mind would run binary encoded events through a testing program that would be provided per language. (May not be automated via travis - but would be easily runnable offline.) The idea being that one could convert binary -> decoded message in the new language -> and back to binary. The round-trip at least guarantees encoding/decoding is symmetric. Having a nice suite of prepared messages is convenient for future language integration.

@bartekn
Copy link
Contributor

bartekn commented May 30, 2018

@nbauernfeind yeah, I think it makes sense. We could create a testing set of XDR definitions (including all standard types) and make sure these are encoded to the same binary form (and the other way: from binary to data) using a different implementations. This shouldn't be hard to do and will provide a good coverage. If you want to work on this, please do it in a separate PR.

@Synesso Synesso mentioned this pull request Dec 7, 2018
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants